tuto bootloader

Le développeur Rei propose la v1.7.1 de son bootloader ReiNX.

Au menu, un écran de démarrage aux couleurs d'Halloween. Ce paramétrage disparaîtra après le 31 Octobre 2018. Le développeur a également mis à jour la stabilité TM.

[+] CLIQUER POUR AFFICHER

Cela était attendu depuis plus d'un mois et SciresM s'est donné du temps pour peaufiner son CFW tout en prenant en compte le firmware 6.0.0, voilà qu'il propose atmosphere-nx dans sa version 0.7 comme cela était prévu !

Il vous faudra:

• L’ensemble des fichiers de l'archive atmosphere-0.7.0.zip à mettre sur votre carte micro SD


• Utilisez le payload fusee-primary.bin via votre PC

Il annonce que le payload peut se lancer via Hekate puisque ce dernier intègre cette possibilité ! Toutefois, le développeur tumGER indique cela:

tumGER Wrote:Veuillez noter que je vais ajouter fusee comme payload dans le très bientôt ™ v10 (avec nos petites modifications personnalisées pour le rendre un peu plus froid <: rooEZ: 399827519286542336>)

• Si vous utilisez hekate, vous avez déjà l'expérience Atmosphere - Ne laissez pas tomber les fonctionnalités et ne vous contentez pas de leur chargeur de démarrage avec des fonctionnalités presque identiques pour les utilisateurs finaux.


• Si vous voulez toujours le tester ** et le charger sur hekate ** -
  1. Supprimez "fusee-primary.bin" dans "bootloader / payloads"
  2. Placez fusee-secondary.bin à la racine.

Je suis vraiment content pour l'équipe et je les remercie pour tout leur travail, sans eux il n'y aurait pas un seul CFW sur le marché.

Edit: Tutoriel actualisé mais il faudra que j'y revienne pour certains aspects après tests !

Edit 2: Démarche actualisée pour lancer atmosphère via hekate car j'avais une erreur. Grâce à l'indication de tumGER, problème résolu. La v10 de SDFilesSwitch viendra apporter le soutient correct du CFW atmosphère. Patience !

-------------------------
Autres infos:

HBLoader (aka HBL) propose sa version 2.0 en NSP pour accompagner le CFW atmosphère.

Le fichier binaire fourni est un fichier ExeFS PFS0.nsp, qui peut être placé dans /atmosphere/hbl.nsp ou chargé via une autre méthode de remplacement ExeFS.

ChangeLog

[+] CLIQUER POUR AFFICHER

• Prend désormais en charge l’exécution en tant qu’application avec un accès à la totalité des ~ 3,2 Go de RAM réservée aux applications, tout en restant compatible avec les anciens homebrew NRO. L'exécution en tant qu'applet de bibliothèque est toujours prise en charge, bien qu'elle n'ait accès qu'à 442 Mo de RAM.


• Autorise l'accès à toutes les autorisations FS.


• Autorise accès utilisateur / hôte à tous les services.


• Autorise l'accès au débogage de SVC.


• Accès à core3 afin de résoudre les problèmes de stabilité lors de l’utilisation préventive de threads multithread et d’équilibrage de charge.


• Ajout de la prise en charge de la clé ABI homebrew de RandomSeed, ce qui permet à l'homebrew de NRO d'utiliser les fonctions libnx randomGet * sans toujours obtenir les mêmes résultats tout au long d'une session unique de nx-hbloader.


• NPDM personnalisé construit à partir de la source.
  
  • Le type d'application par défaut du noyau limite le type à applet (2). Les utilisateurs d’Atmosphère ne sont pas concernés par cette modification, car sa prise en charge native de nx-hbloader définit automatiquement le type d’application approprié

Source: https://github.com/switchbrew/nx-hbload ... tag/v2.0.0

Tout ce qu'indique roukxwel est la possibilité du moment. Ce qu'il manque à la Switch est un utilitaire comme FBI, qui permettrait de supprimer, entre autres, les données du jeux et du ticket (sans oublier les possibilités de l'outils qui sont nombreuses).

Avec SX OS, il n'y a pas cela. Et avec les bootloader, tinfoil est dépourvu de cela également.

En termes de projet, la v2.0.1 de Xecuter corrige les bogues sur 6.0. Toutefois, rien pour l'emuNAND, dans son état actuel.

Il y a une beta v2.1 mais elle se concentre sur sa fonction de Cheat Code qui s'alimente petit à petit.

Dans tous les cas, le online est toujours déconseillé.

Et si tu souhaitais mettre à jour, il te faudra restaurer ta NAND propre en 5.1.0 avant de te lancer dans cette update. Ainsi, tu seras certain qu'aucune trace de NSP ou autres y seront. Ou alors, il faut passer par ChoiDujourNX mais c'est une autre histoire que je relate dans la FAQ du Tutoriel.

Nop, ce dont tu parles concerne le SX OS et sa version 2.0 qui est boguée.
Il n'existe pas ce moyen avec les bootloader pour le moment.

Tu parles de l'emuNAND mais en rien cela est moins risqué. Tout du moins proposée ainsi. Cela n'a rien à voir avec ce qui existe sur 3DS par exemple. Cette partition se fait directement sur la NAND (eMMC) mais est détectable par Nintendo.

J'en parle déjà dans le Tutoriel qui concerne SX OS. Pas besoin des liens que tu proposes.

MDProz Wrote:La Team Xecuter ajoute l'emuNAND avec sa v2.0. Toutefois, ce n'est pas une vraie emuNAND. Il s'agit d'une partition de la NAND de 15Go, un partage entre votre sysNAND et votre emuNAND. Le principe aurait été mieux de virtualiser une seconde NAND sur la carte SD sans altérer la NAND principale mais ce n'est pas le cas !

eliboa Wrote:
Il faut savoir que le module de télémétrie (qui collecte les données et les envoi à Nintendo lors d'un crash), Creport, détecte la taille de votre NAND (NANDTotalSize). Nintendo sera donc en mesure de détecter l'emuNAND de la TX. Vous êtes prévenus !

L'emuNAND de la TX fonctionne comme une emuNAND classique :
- Installer un firmware différent que celui de votre sysNAND sera possible. Ainsi vous gardez votre OFW sur la version la plus basse.
- Tous les homebrews et jeux installés sur votre emuNAND ne seront pas accessibles via l'OFW. Cela devrait, en théorie, échapper à toute détection de la part de Nintendo mais rien ne le confirme ni l'infirme !

La scène est à son début donc pour le moment, parler d'outils pour se prémunir du ban est un peu juste tant le développement prend forme petite à petit. Les bootloader sont les prémices du hack et le CFW atmosphère est issu de cette utilisation que nous en faisons. Ce que je veux dire par là, c'est que les travaux de SciresM et d'autres sont la base de ce qui existe actuellement.

Pour ce qui est du online, il faut partir du principe qu'à partir du moment qu'une console est modifiée, cela est à proscrire même si des outils seraient proposés pour se prémunir du ban. Il suffit de regarder la scène underground PS3 pour s'apercevoir que le risque zéro n'existe pas. L'ensemble des firmes ont basé leur développement sur le online. C'est leur bénéfice et elles ne lâcheront rien en termes de sécurité.

Pour en revenir à ton cas, le mode autoRCM te sera utile pour utiliser ChoiDujourNX mais à l'issu, tu peux le désactiver. Tu grilleras tes eFuses car le downgrade te t'intéresse pas tant que cela selon tes demandes depuis. Sinon, tu peux restaurer ta NAND propre et faire la mise à jour 6.0.0 sans passer par celui-ci.

Après, si tu es déçu d'avoir fait la mise à jour en 5.1.0, je te dirais de patienter le temps que Xecuter propose une version 2.1 qui permettra une emuNAND aboutie peut être. Ainsi, ta SysNAND sera en 5.1.0 et ton emuNAND pourra être en 6.0.0.
C'est aussi cela, l'aspect de l'emuNAND.

Pour ce qui des updates de jeu et DLC, s'ils venaient à demander le FW 6.0.0 pour ceux que tu utiliserais, tu auras un message tout simplement. Et ce avant l'installation et détection de ton firmware. Après, je ne sais comment SX OS va évoluer pour cet aspect.

Pour tinfoil qui s'utilise avec les bootloader, le fait de pouvoir ignorer cela a aussi ces limites à un moment donné. Reste à voir comment cela évoluera aussi.

Donc il faudra être patient et voir comment la scène va évoluer. Dans tous les cas, SciresM, développeur de atmosphère n'a pas l'ambition de proposer quelques aspects que ce soit pour ce qui est de la gestion des backups. D'autres non plus d'ailleurs mais cela ne veux pas dire qu'un Dev ne s'en préoccupera pas. Rien ne le confirme mais rien ne l'infirme. Tinfoil existe bien à ce niveau mais sera t-il la solution qui perdurera ? C'est peu probable car d'autres sont en développement mais rien ne fuite à ce niveau. Chaque scène à eu son lot de gestionnaires de backup.

Les bootloader actuels font le taff. Après, mais il faudra encore être patient, le CFW freeware sera atmosphere-nx de SciresM. Pour le moment, il est toujours en développement suite à la libération du FW 6.0.0. Le développeur s'est accordé un moment avant de libérer une première version de son CFW afin d'analyser cette version comme il se doit.

Oui, si le mode RCM se déclenche, tu peux essayer d'injecter Hekate, ReiNX ou RajNX. Il y a aussi Fusée Gelée qui est le test premier pour être certain mais les bootloader le confirmeront sans problème

Le développeur Rei propose la version 1.7 de ReiNX. La partie du tuto qui concerne le bootloader en FAQ nécessite une actualisation mais rien d'insurmontable si vous souhaitez l'utiliser via Hekate. La démarche reste à peu près la même.

Vous pouvez également l'utiliser directement associé avec son toolkit.

Et si vous n'êtes pas certains de ce que vous faites, SDSetup vous sera utile.

ChangeLog

[+] CLIQUER POUR AFFICHER

• Les modifications utilisateur:
  
  • fs_mitm accroît la prise en charge de la version 6.0
  
  
  • Le texte de débogage ReiNX apparaît uniquement si vous démarrez en mode prolixe (maintien du démarrage)
  
  
  • Boot ReiNX sans carte SD
  
  
  • Tous les kips sont compilés et regroupés avec ReiNX. La boîte à outils peut être utilisée pour les activer / désactiver. (alternativement il suffit de les déplacer de sysmodules.dis à sysmodules, et vice versa)


• Modifications techniques:
  
  • Réécriture du code Kernel

Le développeur CTCaer propose la version 4.2 de son bootloader Hekate.

ChangeLog

[+] CLIQUER POUR AFFICHER

• Prise en charge du caractère générique du dossier "*" dans la clé kip1
  
  Utiliser <folder> / * peut maintenant analyser et charger tous les fichiers kip et kip1 dans ce dossier.


• Ajouter une option pour activer / désactiver la désactivation automatique de HOS
  
  Si vous n'utilisez pas de puce / dongle, vous trouverez peut-être que cette fonctionnalité est ennuyeuse. Options-> Auto HOS hors tension pour désactiver.


• Autoriser l'annulation du processus de vérification
  
  Vous pouvez maintenant annuler le processus de sauvegarde et de vérification. Si la phase de sauvegarde est terminée, l'annulation de la vérification conservera vos fichiers.


• Quelques petites corrections de bugs et supporte certains cfw sur sa version stock

Pour compléter ton lien, le développeur Mike Heskin aka hexkyz a déchiffré la v2.0 de SX OS.

Ce qui ressort:

[+] CLIQUER POUR AFFICHER

• SX OS silencieusement "implémenté" soutien pour IPS32 Patching (sous "sxos/exefs_patches")


• Tout est géré au démarrage qui commence par le montage de 3 dispositifs: "0:" (sdcard), "1:" (EmuNAND) et "3:" (NAND original)


• La partition NAND d'origine est rétrécie à environ la moitié de sa dimension


• Les contenus NAND originaux sont copiés dans l'espace libre;


• Deux blocs (0x200 bytes et 0x1000 bytes) sont écrits dans la partition Calo d'origine de la NAND (au décalage 0x3C0000). Les 0x200 bytes bloquent les êtres avec la valeur magique "EMUNAND0".


• Au démarrage, le bootloader vérifie la magie "EMUNAND0" et si elle le trouve, la deuxième copie NAND sera utilisée à la place


• Point de bonus: le bootloader vérifie maintenant si TPIDR_EL2 est défini et si elle est, EmuNAND est fortement désactivée et l'utilisateur sera toujours au démarrage dans le menu bootloader
  
  • Le commutateur n'utilise pas EL2, mais vous pouvez vous rappeler un certain projet qui est prévu sur l'utilisation de EL2 pour EmuNAND (sous entendu d'un projet prévu avec atmosphère)